Configuring App Icons, Splash Screens, Permissions, and App Metadata in React Native

Course: React Native Training

Topic: Configuring App Icons, Splash Screens, Permissions, and App Metadata

Course Link: React Native Training at JustAcademy

Demo Link: Register for a Course Demo

Website: JustAcademy

1. Introduction

Configuring app icons, splash screens, permissions, and app metadata is an important part of developing a professional React Native application. These configurations control how an application appears on a device, what device features it can access, how it is identified by the operating system, and how it is prepared for distribution.

React Native allows developers to share much of their JavaScript and React code between Android and iOS. However, each platform has its own native configuration system. Android commonly uses Gradle files, resource directories, and AndroidManifest.xml, while iOS uses Xcode project settings, asset catalogs, and Info.plist configuration.

Developers must understand both platforms to prepare an application that looks consistent, requests permissions responsibly, and can be released successfully.

1.1 Learning Objectives

• Understand app icons and their role in mobile application branding.
• Configure launcher icons for Android and iOS.
• Understand native splash screens and launch-screen behavior.
• Configure permissions for sensitive device features.
• Understand Android application IDs and iOS bundle identifiers.
• Configure app names, version numbers, and build numbers.
• Understand the difference between native metadata and app-store listing metadata.
• Test configuration changes on emulators, simulators, and physical devices.
• Prepare a React Native application for release.

2. Understanding App Icons

An app icon is the visual symbol that represents an application. Users generally see it on the device home screen, app drawer, settings screens, and application store listings.

2.1 Importance of App Icons

• Brand identity: Helps users recognize the application.
• Discoverability: Makes the app easier to identify among installed applications.
• User experience: Provides a polished and consistent appearance.
• Professional presentation: Helps the application look complete and trustworthy.
• Platform integration: Allows the operating system to display the application correctly in its launcher.

2.2 App Icon Design Guidelines

• Use a simple, recognizable symbol.
• Use a high-resolution source image.
• Avoid small text that becomes unreadable at smaller sizes.
• Maintain sufficient contrast between the logo and its background.
• Keep important artwork within the platform's recommended safe area.
• Do not manually round the corners unless a specific asset requirement calls for it; the operating system may apply its own mask.
• Test the icon on light, dark, and visually different device backgrounds.

3. Configuring App Icons for Android

Android launcher icons are commonly stored in the app's native resource directories. Depending on the project, the icon may use multiple density-specific image files and adaptive-icon resources.

3.1 Common Android Resource Structure

android/
└── app/
    └── src/
        └── main/
            ├── AndroidManifest.xml
            └── res/
                ├── mipmap-mdpi/
                ├── mipmap-hdpi/
                ├── mipmap-xhdpi/
                ├── mipmap-xxhdpi/
                ├── mipmap-xxxhdpi/
                └── mipmap-anydpi-v26/

The exact files and directories depend on the project template. Existing projects may contain resources such as ic_launcher.png, ic_launcher_round.png, or adaptive-icon XML files.

3.2 Steps to Configure an Android Icon

1. Prepare a high-resolution square image of the app logo.
2. Generate launcher icon assets for the required Android densities.
3. Place the generated files in the appropriate mipmap-* directories.
4. Configure adaptive-icon foreground and background resources if required.
5. Open android/app/src/main/AndroidManifest.xml.
6. Check the android:icon property inside the application element.
7. Check the round-icon reference if the project uses one.
8. Build and install the app to confirm that the new icon appears correctly.

3.3 Example Android Manifest

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application
        android:name=".MainApplication"
        android:label="@string/app_name"
        android:icon="@mipmap/ic_launcher"
        android:roundIcon="@mipmap/ic_launcher_round">
        <!-- Other application configuration -->
    </application>
</manifest>

This is an illustrative example. Keep the existing application configuration generated by your React Native project and update only the properties required by your app.

3.4 Understanding Adaptive Icons

Adaptive icons allow Android launchers to apply different masks and visual effects to the same icon. They generally contain separate foreground and background layers.

• Foreground: Contains the logo or primary symbol.
• Background: Supplies a background color or image.
• Safe area: Keeps important artwork away from regions that may be cropped by launcher masks.
• Monochrome layer: May be used for themed icons on supported Android versions.

Keep the foreground logo centered and avoid putting important details close to the image edges. Test the icon with different launcher shapes and Android themes.

4. Configuring App Icons for iOS

iOS app icons are generally managed through an asset catalog in the Xcode project. The asset catalog contains the icon assets required for supported devices and distribution configurations.

4.1 Common iOS Asset Location

ios/
└── MyApp/
    └── Assets.xcassets/
        └── AppIcon.appiconset/

Your project may use a different asset catalog name. Use Xcode to inspect the actual structure and the app target's selected icon configuration.

4.2 Steps to Configure an iOS Icon

1. Prepare the icon artwork according to Apple's current requirements.
2. Open the iOS workspace in Xcode, commonly ios/MyApp.xcworkspace in a CocoaPods-based project.
3. Select the application target.
4. Open the asset catalog and select the app icon set.
5. Import the appropriate artwork or use the icon workflow supported by your Xcode version.
6. Confirm that the correct icon set is selected in the target configuration.
7. Build and run the application on an iOS simulator or physical device.

4.3 iOS Icon Best Practices

• Follow the current Apple Human Interface Guidelines and icon requirements.
• Use appropriately sized, square artwork.
• Keep the design clear at small sizes.
• Check how the icon appears in light and dark system appearances when applicable.
• Do not assume that Android adaptive-icon resources can be reused directly as iOS icon assets.

5. Understanding Splash Screens

A splash screen, also known as a launch screen, is the initial visual experience displayed while the operating system starts an application. It may contain a logo, a background color, or other restrained branding elements.

5.1 Benefits of Splash Screens

• Provides a consistent startup appearance.
• Reinforces application branding.
• Creates a smoother transition into the first screen.
• Helps avoid an abrupt change in the interface during startup.

5.2 Splash Screen Best Practices

• Keep the design simple and uncluttered.
• Use a background color that visually matches the first application screen.
• Use appropriately sized artwork.
• Follow the native platform's launch-screen rules.
• Avoid unnecessary startup operations that make the splash screen remain visible too long.
• Do not use a splash screen to hide a slow or unresponsive application.

6. Configuring a Splash Screen on Android

Modern Android versions provide a system splash-screen experience. Configuration generally involves native theme resources and the launch behavior of the application. The exact implementation depends on the Android version, project template, and libraries in use.

6.1 Common Android Files

android/app/src/main/AndroidManifest.xml
android/app/src/main/res/values/styles.xml
android/app/src/main/res/drawable/
android/app/src/main/res/mipmap/

6.2 Configuration Workflow

1. Prepare the launch logo and background color.
2. Inspect the app theme referenced in the Android manifest.
3. Configure the launch theme and splash-screen attributes supported by the project's Android setup.
4. Verify that the launch theme transitions to the normal application theme.
5. Test the application on both older supported Android versions and recent versions.
6. Check cold-start and subsequent-launch behavior.

6.3 Illustrative Android Theme Configuration

<resources>
    <style name="AppTheme" parent="Theme.AppCompat.DayNight.NoActionBar">
        <item name="android:windowActionModeOverlay">true</item>
    </style>
</resources>

This is a simplified theme example, not a complete splash-screen implementation. Your project may use a different theme parent and additional launch attributes. Follow the current Android documentation and preserve existing configuration required by the application.

7. Configuring a Splash Screen on iOS

iOS uses a native launch-screen configuration managed by the Xcode project. Depending on the project template, this may use a launch storyboard or another supported configuration. A native launch screen is not an ordinary React Native component.

7.1 Steps to Configure an iOS Launch Screen

1. Open the iOS workspace in Xcode.
2. Select the application target.
3. Inspect the target's launch-screen configuration.
4. Open the configured launch storyboard or launch-screen resource.
5. Set the background color and supported image assets.
6. Check layout constraints for different screen sizes.
7. Run the application on multiple simulators or physical devices.

7.2 iOS Launch Screen Recommendations

• Keep the launch screen static and visually consistent with the first app screen.
• Use supported native layout and asset mechanisms.
• Avoid trying to run React components or business logic inside the native launch screen.
• Check dark-mode behavior when the app supports it.
• Do not assume that the operating system launch screen can remain visible indefinitely while asynchronous work completes.

8. Using Expo for Icons and Splash Screens

Expo projects can configure app icons and splash screens through the application configuration file and supported config plugins. This approach reduces the need to manually edit native resources for every change.

8.1 Example Expo Configuration

{
  "expo": {
    "name": "Task Manager",
    "slug": "task-manager",
    "icon": "./assets/images/icon.png",
    "plugins": [
      [
        "expo-splash-screen",
        {
          "image": "./assets/images/splash-icon.png",
          "backgroundColor": "#FFFFFF",
          "imageWidth": 200
        }
      ]
    ],
    "android": {
      "adaptiveIcon": {
        "foregroundImage": "./assets/images/adaptive-icon.png",
        "backgroundColor": "#FFFFFF"
      }
    },
    "ios": {
      "bundleIdentifier": "com.example.taskmanager"
    }
  }
}

This example illustrates common configuration options. Ensure that the image files exist and that the configuration matches your Expo SDK version. If you use a bare React Native project without Expo configuration, follow the native setup for that project.

8.2 Important Expo Considerations

• Use the appropriate image formats and dimensions required by the current Expo documentation.
• Use the splash-screen config plugin for supported native splash configuration.
• Rebuild the native application after changing settings that are applied at build time.
• Test the splash screen in an appropriate preview or production build, because Expo Go and development builds may not reproduce the final launch experience exactly.

9. Understanding App Permissions

Permissions control whether an application can access protected device features or user data. Common examples include the camera, microphone, location, photo library, contacts, Bluetooth, and notifications.

Permission configuration often involves two separate steps: declaring the required capability in the native project where applicable, and requesting the user's authorization at runtime when required by the operating system.

9.1 Common Permissions

9.2 Permission Best Practices

• Request only permissions needed by implemented features.
• Ask at an appropriate point in the user journey rather than requesting everything at startup.
• Explain the benefit of access before presenting the system prompt when useful.
• Handle denied, restricted, and unavailable states gracefully.
• Recheck authorization when the app returns to the foreground if appropriate.
• Do not treat a permission grant as a substitute for server-side authorization or application security.

10. Configuring Permissions on Android

Android permissions are commonly declared in android/app/src/main/AndroidManifest.xml. Runtime permission behavior depends on the permission type, Android version, and target SDK.

10.1 Example: Camera Permission

<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <uses-permission android:name="android.permission.CAMERA" />
    <application
        android:label="@string/app_name"
        android:icon="@mipmap/ic_launcher">
        <!-- Application configuration -->
    </application>
</manifest>

This declares camera access in the manifest. It does not automatically grant the permission or guarantee that the system prompt has been displayed.

10.2 Runtime Permission Requests

For protected Android features, the application may need to request permission while it is running. React Native provides PermissionsAndroid for certain Android permissions, while other features may use APIs exposed by a native module or maintained permissions library.

10.3 Example Using PermissionsAndroid

import { PermissionsAndroid, Platform } from 'react-native';

async function requestCameraPermission() {
  if (Platform.OS !== 'android') {
    return false;
  }

  const result = await PermissionsAndroid.request(
    PermissionsAndroid.PERMISSIONS.CAMERA
  );

  return result === PermissionsAndroid.RESULTS.GRANTED;
}

This simplified example returns whether the camera permission was granted. A production implementation should also handle denied and never-ask-again states and provide an appropriate user experience.

10.4 Android Permission Checklist

• Declare the necessary permission in the correct manifest.
• Confirm the permission is appropriate for the target SDK.
• Request runtime access where required.
• Check the result before using the protected feature.
• Offer a reasonable alternative when access is denied.
• Test on different supported Android versions.

11. Configuring Permissions on iOS

iOS requires purpose descriptions for many protected capabilities. These descriptions are commonly configured through keys in the application's Info.plist file.

11.1 Common iOS Usage-Description Keys

This list is not exhaustive. The required keys depend on the API, capability, and operating-system version. Check the current Apple documentation for your exact feature.

11.2 Example Info.plist Entries

<key>NSCameraUsageDescription</key>
<string>We use the camera to let you take profile photos.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>We use photo access so you can choose a profile image.</string>

These entries belong inside the appropriate <dict> element in the app's property list. Use descriptions that accurately reflect the feature and the data being accessed.

11.3 iOS Permission Workflow

1. Add the required purpose description to the native app configuration.
2. Use the relevant React Native API or a supported native library to request access.
3. Check the authorization result.
4. Handle denied or restricted access without crashing.
5. Explain how to change settings when appropriate.
6. Test fresh installation and previously changed permission states.

12. Notifications and Other Special Permissions

Notifications, Bluetooth, background location, and tracking-related capabilities may require additional setup beyond the basic permission examples.

• Notifications: Follow current Android and iOS authorization rules.
• Bluetooth: Declare and request only the capabilities needed for the feature.
• Background location: Requires a justified use case and may involve additional restrictions and declarations.
• Tracking: Follow Apple's applicable authorization requirements when tracking-related APIs are used.
• Media selection: Prefer a system picker when it can satisfy the use case without broad access.

Do not add permissions simply because they might be useful later. Unnecessary permissions can reduce user trust and create store review or policy issues.

13. Understanding App Metadata

App metadata is information that identifies and describes an application. Some metadata is embedded in the native application, while other information is entered in the Google Play Console or App Store Connect.

13.1 Common Metadata Fields

14. Configuring the Android App Name

In many Android projects, the application display name is defined in a string resource and referenced by the manifest.

14.1 Example strings.xml

<resources>
    <string name="app_name">Task Manager</string>
</resources>

The manifest may refer to that resource:

<application
    android:label="@string/app_name"
    android:icon="@mipmap/ic_launcher">
    <!-- Application configuration -->
</application>

Keep the string resource and manifest reference consistent. If the project uses product flavors or build variants, verify the name for each variant.

15. Configuring the iOS App Display Name

The iOS display name can be configured through the CFBundleDisplayName property or the project's Xcode build settings, depending on the project structure.

15.1 Example Info.plist Entry

<key>CFBundleDisplayName</key>
<string>Task Manager</string>

The final configuration depends on how the project manages its property list and build settings. Verify the display name in the built application rather than relying only on the source file.

16. Configuring Application Identifiers

16.1 Android Application ID

The Android application ID identifies the installed application and is used by Android and distribution services. It is commonly configured in the app-level Gradle file.

android {
    namespace "com.example.taskmanager"

    defaultConfig {
        applicationId "com.example.taskmanager"
        versionCode 1
        versionName "1.0"
    }
}

This is an illustrative Gradle snippet. Your project may use different syntax or shared configuration variables. The namespace and applicationId serve different purposes even when they use the same value.

16.2 iOS Bundle Identifier

The iOS bundle identifier is generally configured through the Xcode target's build settings, commonly the PRODUCT_BUNDLE_IDENTIFIER setting.

1. Open the iOS workspace in Xcode.
2. Select the application target.
3. Open the signing and build configuration.
4. Set the intended bundle identifier.
5. Confirm that signing and provisioning settings support the identifier.

16.3 Identifier Best Practices

• Choose a stable identifier controlled by your organization.
• Use a reverse-domain naming convention, such as com.company.product.
• Check uniqueness where required.
• Avoid changing the identifier after publication unless you intend to create a separate app identity.
• Verify development, staging, and production identifiers independently.

17. Version Numbers and Build Numbers

Versioning helps developers, testers, users, and app stores distinguish releases. Android and iOS use platform-specific fields to represent versions and individual builds.

17.1 Android Versioning

• versionName: The user-facing version label, such as 1.2.0.
• versionCode: An integer used to distinguish releases. It generally must increase for each published Android update.

17.2 iOS Versioning

• CFBundleShortVersionString: The user-facing version number.
• CFBundleVersion: The build number associated with the build.

17.3 Example Release Strategy

These values are examples only. Follow current store requirements and your team's release process.

18. Understanding Store Listing Metadata

Native app metadata is different from the public listing displayed in an app store. Store metadata helps users understand the application before installing it.

18.1 Common Store Listing Fields

• App title: The public name of the application.
• Short description: A concise summary of the app's benefits.
• Full description: Information about features and functionality.
• Screenshots: Images demonstrating important screens.
• Store icon: Artwork that follows the store's requirements.
• Privacy policy: A policy link where required.
• Support information: Contact details or a support website.
• Category and age rating: Classifications required by the store.

18.2 Native Metadata vs Store Metadata

19. Complete Configuration Workflow

1. Review the project: Identify whether it uses bare React Native, Expo, or another supported workflow.
2. Prepare assets: Create the app icon, adaptive-icon layers if needed, and splash-screen artwork.
3. Configure Android: Check launcher resources, app label, permissions, theme, application ID, and version values.
4. Configure iOS: Check icon assets, launch screen, usage descriptions, display name, bundle identifier, and version values.
5. Review permissions: Remove unnecessary declarations and confirm that each permission serves a genuine feature.
6. Validate metadata: Check names, identifiers, version values, and build settings for the intended release.
7. Build the app: Generate an appropriate Android or iOS build.
8. Test on devices: Check the installed icon, launch experience, permissions, and device settings.
9. Prepare store listings: Add descriptions, screenshots, privacy details, and other required information.
10. Validate release readiness: Check signing, identifiers, build numbers, and store requirements before submission.

20. Testing App Icons and Splash Screens

20.1 App Icon Test Cases

• Confirm that the icon appears correctly on the home screen and in the app drawer.
• Check that adaptive-icon artwork is not unexpectedly cropped.
• Test the icon against different launcher themes and backgrounds.
• Verify that the release build uses the correct icon.
• Check store listing artwork separately from the installed application icon.

20.2 Splash Screen Test Cases

• Perform a cold launch after fully closing the app.
• Launch the app after returning from the background.
• Check the transition to the first React Native screen.
• Test different screen sizes and supported operating-system versions.
• Check light and dark appearance where supported.
• Confirm that startup errors do not leave the application stuck on a loading screen.

21. Testing Permissions

Permission testing should cover both the initial request and changes made later through device settings.

22. Common Problems and Troubleshooting

22.1 App Icon Does Not Change

• Check that the correct resource or asset catalog is selected.
• Verify filenames and resource references.
• Confirm that the intended build variant is being installed.
• Rebuild the native application after changing assets.
• Uninstall and reinstall the app if the launcher appears to be caching the old icon.

22.2 Splash Screen Shows the Wrong Image

• Verify the selected launch-screen resource or configuration.
• Check the image path, dimensions, and supported format.
• Confirm that the intended build profile is being used.
• Rebuild the native app after configuration changes.
• Test an appropriate preview or release build if the development environment changes the launch experience.

22.3 Permission Prompt Does Not Appear

• Check whether permission was already granted or denied.
• Confirm the native declaration or purpose description is present where required.
• Verify the target SDK and operating-system version.
• Ensure that the correct permission API is being called.
• Check whether the permission is restricted or must be enabled in system settings.

22.4 iOS Permission Error

• Confirm that the required usage-description key exists in the final app configuration.
• Check the spelling and placement of the property-list key.
• Ensure that the requested API matches the declared purpose.
• Rebuild the application after native configuration changes.

22.5 App Name or Identifier Is Incorrect

• Check Android string resources and manifest labels.
• Check the iOS display-name setting and target build configuration.
• Verify the application ID or bundle identifier for the active build variant.
• Review environment-specific configuration files and build scripts.

23. Best Practices

• Keep app icons simple, recognizable, and consistent with the brand.
• Use native launch-screen mechanisms instead of treating the splash screen as an ordinary React component.
• Keep startup work efficient and minimize unnecessary delays.
• Request sensitive permissions only when users need the associated feature.
• Write accurate and user-friendly permission descriptions.
• Keep application identifiers stable after publication.
• Increment version and build values according to platform rules.
• Maintain separate development, staging, and production settings where necessary.
• Test release builds on physical devices before publishing.
• Review current Android, Apple, React Native, and Expo documentation before changing native configuration.

24. Practical Project: Configure a Task Manager App

Create a small React Native Task Manager app and prepare its configuration for release.

24.1 Project Requirements

• Set the display name to Task Manager.
• Create a recognizable application icon.
• Configure a native splash screen that matches the app branding.
• Set appropriate Android and iOS identifiers.
• Configure version and build metadata.
• Add only the permissions required by the implemented features.
• Test the app on Android and iOS.

24.2 Project Steps

1. Create a React Native project using the workflow selected for the course.
2. Prepare icon and splash-screen artwork in an asset directory.
3. Configure platform-specific icons and launch screens.
4. Set the application name and identifiers.
5. Implement a feature that genuinely needs a permission, such as choosing a profile image.
6. Test both granted and denied permission states.
7. Generate a release build and verify the installed application's appearance and metadata.

24.3 Expected Outcome

The completed application should display the correct identity on the device, launch with a consistent visual experience, request permissions responsibly, and use appropriate identifiers and version information.

25. Interview Questions and Answers

Q1. What is an app icon?

An app icon is the visual identifier used by the operating system and app stores to represent an application.

Q2. What is a splash screen?

A splash screen is the initial launch experience displayed while the operating system starts the application and prepares to show its first screen.

Q3. Are app icons configured identically on Android and iOS?

No. Android commonly uses launcher resources and adaptive-icon layers, while iOS generally uses an Xcode asset catalog or a supported icon configuration workflow.

Q4. Why does an app need runtime permissions?

Runtime permissions allow users to control access to protected device features and personal data.

Q5. What is the purpose of an iOS usage-description key?

It explains why the application needs access to a protected resource such as the camera or photo library.

Q6. Is declaring an Android permission enough to grant access?

No. Some permissions also require a runtime request and user approval. The exact behavior depends on the permission and platform version.

Q7. What is an Android application ID?

It is the identifier used by Android and distribution services to distinguish an application.

Q8. What is an iOS bundle identifier?

It is the identifier associated with an iOS application target and its distribution configuration.

Q9. What is the difference between a version name and a build number?

A version name communicates the release version, while a build number or platform-specific build identifier distinguishes individual builds.

Q10. Why should an app request the minimum necessary permissions?

Minimizing permissions protects user privacy, improves trust, and reduces unnecessary platform and review complications.

Q11. Why might a splash screen look different in a development build?

The development environment, cached native resources, or build configuration may affect the launch experience. An appropriate preview or release build helps validate the final result.

Q12. What should be checked before publishing a React Native application?

Verify icons, launch screens, permissions, app names, identifiers, version numbers, signing configuration, store listing information, and release-build behavior.

26. Practice Exercises

1. Design an app icon and configure it for Android and iOS.
2. Change the application display name to a custom product name.
3. Configure a launch screen that matches the first app screen.
4. Declare and request camera access for a genuine feature.
5. Write an accurate iOS camera usage description.
6. Change the app version and build identifier for a test release.
7. Test the application after denying permission and later changing it through device settings.
8. Prepare a release checklist covering platform assets and metadata.

27. Quick Revision Checklist

• App icon assets are configured separately for Android and iOS.
• Android adaptive-icon layers are checked where applicable.
• The native launch screen is configured and tested.
• Permission declarations and runtime requests match the implemented features.
• iOS purpose-description keys are present where required.
• The app display name is correct on each platform.
• The application ID and bundle identifier are correct.
• Version and build identifiers follow release rules.
• Store listing metadata and privacy information are ready.
• Release builds have been tested on supported devices.

28. Official Learning Resources

• React Native: PermissionsAndroid
• React Native: Images and Assets
• Android Developers: Splash Screens
• Apple Developer: Asset Management
• Apple Developer: Specifying Your App's Launch Screen
• Expo: Splash Screen and App Icon Configuration
• Expo: Configuring App Permissions

29. Conclusion

Configuring app icons, splash screens, permissions, and metadata is an essential step in preparing a React Native application for production. App icons establish visual identity, launch screens create a consistent startup experience, permissions protect user privacy, and metadata helps the operating system and app stores identify the application correctly.

Since Android and iOS use different native configuration systems, each platform should be validated independently. By following a structured workflow, testing permission states, and reviewing release requirements, developers can create React Native applications that are polished, reliable, and ready for distribution.

Explore the course: React Native Training

Register for a demo: JustAcademy Course Demo

Visit JustAcademy: https://www.justacademy.co/